Current implementations of UNIX-related operating systems provide a kernel mechanism known as "STREAMS" for supporting development of network services and data communication drivers. In particular, the kernel mechanism allows for the setting up of a "stream" between a user-space process and a driver; a "stream" is a full-duplex processing and data transfer path in the operating system kernel between the user-space process and driver.
The STREAMS mechanism is well documented and a good introduction to the subject may be found, for example, in "UNIX System V/386, Release 3.2, Streams Primer" AT&T, published by Prentice Hall, 1989. Nevertheless, to facilitate an understanding of the present invention without reference to other documents, a brief description of the components of a stream and of the connection of a stream to a multiplexer driver will now be given with reference to FIGS. 1 and 2 of the accompanying drawings.
FIG. 1 is a diagrammatic illustration of the basic components of a stream 10. As already noted, a stream is a full-duplex processing and data transfer path between a driver 11 in kernel space and a user process 12 in user space. A stream will always have a stream head 13 and a stream end, the latter being constituted by the driver 11. The stream head 13 provides the interface between the stream 10 and the user-space process 12 and its main function is to process streams-related user system calls. The stream end driver may be a device driver providing services to an external I/O device or an internal, "pseudo" device driver such as a multiplexer driver.
In addition to its stream head and stream end, a stream may have one or more modules 15 inserted between the stream head and stream end and serving to perform intermediate processing of data.
Data is passed from the driver 11 to the user-space process 12 and from the user-space process 12 to the driver 11 in messages.
The opening, control and closing of a stream is effected by the user-space process by issuing system calls which are serviced by a kernel mechanism represented in FIG. 1 by the streams control block 16. Thus, to form the FIG. 1 stream, the user-space process 12 must first issue a system call (an "open" call) requesting the streams control block 16 to open a stream between the user-space process and the driver 11, and then issue another system call (an ioctl "push" call) to add the module 15 to the stream. The ioctl push call is actually processed by the stream head 13 which uses the services of the block 16 to execute the push.
FIG. 2 shows a more complicated streams example; it should be noted that in this FIG. (and also in subsequent FIGS.) the full-duplex nature of a stream is indicated by double-headed arrows used between the stream components rather than the more explicit separate up and down paths shown in FIG. 1. Furthermore, for clarity the streams control block has been omitted.
In FIG. 2, a plurality of streams are interconnected by a multiplexer driver 20. The multiplexer driver 20 shown is a lower multiplexer in that it multiplexers multiple lower streams 21, 22, 23 (that is, streams nearer device drivers) into a single upper stream 24 (the stream nearer the user-space process); upper multiplexers are also possible in which multiple upper streams are multiplexed into a single lower stream. Whether an upper or a lower multiplexer, the multiplexer driver 20 comprises a functional entity that serves to multiplex/demultiplex the streams operationally associated with it.
To form the FIG. 2 arrangement, the user-space process 12 first issues system calls to open streams 21, 22 and 23 to each of the device drivers 11A,B,C and stream 24 to the multiplexer driver 20. Next, the user-space process 12 issues push system calls to push the required modules 15A,B,C onto streams 21, 22 and 24. Finally, the user-space process issues appropriate ioctl calls to link the streams 21, 22 and 23 below the multiplexer driver 20.
The present invention relates to a computer system provided with an operating system having a streams facility generally of the form described above. More particularly, the present invention relates to a computer system of the type having operating system means for providing system resources to user-space processes run by the computer system, the operating system means including a device driver; a multiplexer driver comprising a multiplexer functional entity for multiplexing/demultiplexing streams operationally associated therewith; and stream-control means for opening a stream between a said user-space process and said device driver in response to a first system call from said user-space process, and for linking a said stream previously opened between said user-space process and device driver, to said multiplexer driver in response to a second system call from said user-space process.
A drawback of the known streams multiplexer arrangments is that the dynamic provision of extra streams to the multiplexer driver must be controlled by the user-space process served by the multiplexer driver. This generally requires each application to have specially written code to provide this facility.
It is an object of the present invention to provide an improved way of enabling the dynamic provision of extra streams to a multiplexer driver in a computer system of the aforesaid type.